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With the introduction of the 2B Extended Feature Generic #3 (2BE3), No. 
2B Electronic Switching System has modernized its arrangements for billing 
and traffic measurements. High-speed, synchronous data links are used to 
teleprocess billing information to the No. 1A Automatic Message Accounting 
Recording Center and to forward traffic data to the No. 1A Engineering and 
Administrative Data Acquisition System Center. This article describes the 
implementation of these features in the 2BE3 generic and how these new 
interfaces have resulted in more precise and more reliable data. 



I. INTRODUCTION 

The billing and traffic measurements capabilities available in the 
No. 2B Electronic Switching System (ESS) + today are the culmination 
of an evolutionary process spanning more than a decade. During that 
period, the ESS environment was changing at a very rapid pace, and 
as a result the billing and traffic measurements processes were contin- 
ually being upgraded to meet the demands for each generic. Repre- 
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senting the latest capabilities for billing and traffic measurements in 
the No. 2B ESS are the No. 1A Automatic Message Accounting 
Recording Center (AMARC) Interface feature and the No. 1A Engi- 
neering and Administrative Data Acquisition System (EADAS) fea- 
ture, respectively. Both the AMARC and EADAS features require 
near-real-time data collection at the No. 2B ESS. The data are then 
passed to I/O message buffers for subsequent transmission to an 
AMARC or EADAS data center. The AMARC formats the billing 
information for a Revenue Accounting Office (RAO) to use in prepar- 
ing customer bills, while EADAS provides real-time surveillance and 
disperses traffic data to various Operation Support Systems (OSSs) 
for use in maintaining the switching system and planning future 
growth. Data to the AMARC and EADAS systems are transmitted via 
synchronous, 2.4-kb data links using the BX.25 protocol. The AMARC 
feature also uses 4.8-kb data links for those offices presenting too large 
a load for the 2.4-kb link. 

1.1 No. 1 A AMARC 

Although several hardware and software versions of an AMARC 
exist today, the No. 2B ESS interfaces only with the No. 1A AMARC 
equipped with the 1AAM4 generic. The AMARC provides service to 
various types of switching systems today with several different inter- 
faces giving flexible format, protocol, and data-link speeds between 
the switching systems offices and AMARC. The AMARC combines 
the data received from the switching systems into a format acceptable 
by an RAO. The data are then recorded on magnetic tape, which is 
sent to the RAO for processing into telephone bills for the customers. 
Figure 1 represents the interface of a No. 2B ESS with an AMARC. 

1.2 EADAS 

An EADAS data center (with the 1AED4 generic) connected to the 
No. 2B ESS (with the 2BE3 generic) receives traffic data and plant 
data from the No. 2B ESS. The traffic data are load measurements 
such as peg and usage counts for office totals, and peg, usage, and 
overflow counts for trunk and service circuit groups. The plant data 
are measurements that indicate the health of the system. Examples 
are control unit and peripheral unit diagnostic all-tests-passes and 
faults. The traffic and plant data sent to EADAS and processed by 
the EADAS data center are then used by other associated OSSs. The 
Network Operations Report Generator (NORGEN), part of EADAS, 
accesses the processed EADAS data directly for its near-real-time 
reports. Downstream OSSs process EADAS data after they have been 
sent to them via magnetic tape. Two such downstream OSSs to access 
the data via the Traffic Data Administration System (TDAS) are 
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Fig. 1— Interface of a No. 2B ESS with an AMARC. 

SPCS COER (Stored Program Control Systems Central Office Equip- 
ment Reports) and TSS (Trunk Servicing System). The reports gen- 
erated by SPCS COER and TSS are needed by network administrators 
to monitor switching system services, measure utilization, and calcu- 
late capacity of the switches, and by trunk administrators to compute 
trunk group traffic load and current trunk requirements as part of 
their day-to-day jobs. The capability of providing timely data to SPCS 
COER and TSS is advantageous (see Fig. 2 for layout). The OSSs can 
now develop additional needed reports (e.g., summarizing centrex 
group counts). Also, with the addition of RSS host capability in 2BE3, 
the traffic data for an RSS is collected by the No. 2B ESS. Extreme 
Value Engineering (EVE) techniques are used for the engineering of 
an RSS. The EVE selection is done by EADAS and the engineering 
calculations are done by SPCS COER. 

II. No. 2B ESS HISTORY AND LIMITS 
2. / Billing data collection 

Prior to the installation of the 2BE3 generic, the primary method 
of billing calls was through Local Automatic Message Accounting 
(LAMA). Other methods used to a lesser degree were Centralized 
Automatic Message Accounting (CAMA) and in some instances mes- 
sage registers. The choice of billing arrangement was based on appli- 
cable tariffs (flat rate or local measured service) and resulting call 
volumes. Flat rate areas used message registers or CAMA while local 
measured service areas used LAMA. 
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Fig. 2— No. 2B ESS and Operation Support Systems. 



The LAMA version of No. 2B ESS billing provides the most com- 
plete and versatile billing process. However, in some cases daily 
collection of LAMA tapes could be costly. One possible solution to 
this first problem was to enhance the software and upgrade the tape 
recorder to accommodate full measured service billing. However, the 
collection of the tapes on a daily basis still presents an unattractive 
cost factor. 

2.2 Traffic data collection 

In a No. 2B ESS office, each teletypewriter (TTY) will serve as a 
primary output device for one function. A 110-baud data link could be 
connected from the traffic TTY controller circuit to an EADAS 
monitored interface. Once it is output to any device, the data no longer 
exist in the corresponding register, and subsequent output to any other 
device is not possible. In addition, a large office could not transmit all 
of the data to EADAS because of the limited data-link speed. Thus, 
only a subset of the total data was sent (i.e., one or two hours worth 
each day, assigning different data to the schedules). Another problem 
was the data skew associated with these output processes. The TTY 
print rate was 10 characters per second. At this rate it took a minimum 
of 5 minutes to print a traffic schedule of 600 registers. (Most No. 2B 
offices have more than 600 registers on a schedule and some require 
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15 minutes print time for even larger schedules.) The last line of data 
on a printed schedule is therefore skewed from the first line by the 
print time. To solve the need for all the data all the time and for 
accurate data (i.e., prevent data skew) holding registers are added to 
the 2BE3 generic. 

III. SOLUTION AND NEW PROBLEMS 

The inclusion of AMARC and EADAS in the 2BE3 generic provides 
the increased billing capacity required by the switch and improved 
traffic information for engineering the switch. This does not preclude 
the use of billing arrangements available prior to 2BE3 (e.g., LAMA), 
where increased billing capacity is not required. Also, most of the 
traffic information capabilities available prior to 2BE3 have been 
retained. However, as with any new approach, new problems appeared 
for both AMARC and EADAS. In the early planning phase, one of the 
more basic problems was establishing interface requirements accept- 
able to Bell Laboratories systems engineering, AMARC development, 
EADAS development, and the No. 2B ESS development organization. 
The selection of a data- link protocol that could be used for both 
EADAS and AMARC was a highly desirable consideration. Also, 
during this same time frame, No. 5 ESS committed to AMARC and 
EADAS for its first application. This further complicated the situation 
in that now there was another system with a dissimilar architecture 
and software environment that could affect the development schedule 
and interface requirements. 

IV. NEW PROTOCOL 

Selection of the communications protocol was a major consideration 
in establishing AMARC and EADAS requirements. A protocol repre- 
sents a formal agreement on the exchange of information between two 
or more entities. It provides a multilayered set of rules that govern the 
interconnecting electrical signals (level one), packetized data (level 
two), complete message (level 3), and user application data transfer 
procedures (level 4 and above). Several protocols were considered, e.g., 
DDCMP, BYSYNC, X.25, etc., but only X.25 had the recommendation 
of the Comite Consultatif International Telephonique et Telegrap- 
hique (CCITT). Eventually a subset of X.25, now referred to as BX.25, 
was proposed and accepted as the AMARC feature protocol. Subse- 
quent investigation of this proposal revealed that the proposed BX.25 
protocol was also suitable for the EADAS feature. A more detailed 
presentation of this capability in the No. 2B ESS 2BE3 generic is 
provided in this issue of the Journal in an article entited "Adding 
Data Links to an Existing ESS." 
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V. INTEGRATION OF AMARC 

The AMARC feature encompassed many areas of call processing as 
well as data integrity and transmittal. Some areas were related to 
AMARC alone, while others were a consequence of a retrofit constraint 
that required simultaneous recording by AMARC and LAMA. Rather 
than attempting to cover the entire scope of AMARC, we will discuss 
only the basic operational capability and selected concerns. 

5. 1 Basic operation 

The AMARC feature collects billing data in real time in the No. 2B 
ESS and then transmits this data using either a dedicated 2.4- or 4.8- 
kb/s full-duplex transmission facility or an automatic -dialed backup 
data-link facility of the same transmission speed in case of primary 
link failure. The No. 2B ESS/AMARC interface uses a double-entry 
billing system consisting of an initial/answer entry and a disconnect 
entry. LAMA recording, however, uses a triple-entry billing system 
consisting of initial, answer, and disconnect entries. Data for each 
LAMA entry are collected in real time and loaded into a dedicated 
LAMA buffer prior to being directed to the tape recorder via I/O 
control at interrupt level. The use of special AMA registers allows the 
basic billing structure to remain as it had been for LAMA and still 
achieve the double-entry billing required by AMARC. Each AMA 
register is linked with a specific call by direct extension of the Tran- 
sient Call Record (TCR) memory already designed into the No. 2B 
ESS architecture. These TCR extensions are then referred to as TCRX 
registers. The initial billing data are collected and placed into the 
TCRX registers until answer time and then, upon verification of 
Minimum Chargeable Duration (MCD), the data are moved into an 
AMARC data buffer. At disconnect, the data are again collected in 
the TCRX. When the entry is assembled, it is then loaded into the 
AMARC data buffer. 

5.2 Entry association 

An obvious requirement for assembling the double entry into one 
call record by AMARC is the need to associate the initial/answer 
entry with the corresponding disconnect entry. The method provided 
by the No. 2B ESS is to map an equipment number (the physical 
location of a call on the No. 2B ESS or RSS network) into a 15-bit 
Virtual Equipment Number (VEN) and record the VEN as the low- 
order 16 bits of a 24-bit Call Assembly Index (CAI) that accompanies 
each billing entry. The CAI high 8 bits are zeroes except for the case 
of call-forwarded calls. The special use of the high 8 CAI bits for call- 
forwarded calls will be described later in this article. 

The CAI counterpart in LAMA recording is the Call Identity Index 
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Fig. 3— Basic billing information flow between internal AMARC registers and buffers. 

(CII). LAMA recording guaranteed that CIIs appearing on the tape 
would be unique for the duration of a call by maintaining a table of 
the active CIIs derived using a time-consuming hashing scheme based 
upon the VEN. Since the method of call sequencing associated with 
the CAI no longer requires the ESS to provide a hashing algorithm, 
significant real-time savings are achieved for the No. 2B ESS call- 
processing execution environment. Figure 3 represents the basic billing 
information flow between internal AMARC registers and buffers. 

5.3 AMARC data buffer 

The No. 2B ESS AMARC data buffer is an engineerable area of 
read/write memory. The maximum size is designed to provide up to 
two minutes of billing data storage during a data-link failure. Auto- 



BILLING AND MEASUREMENTS 1543 



matic recovery to the dialed backup data link can be obtained within 
this two-minute period. The buffer is segmented into message size 
entities of 512 bytes each. When a buffer segment has insufficient 
room for the next data entry, or a fixed time limit has expired, the 
data are either sent immediately or queued for later transmission 
through the I/O program. The decision depends on available buffer 
space on the Serial Peripheral Unit Controller for Data Links (SPUC/ 
DLs). Further information on this subject can be found in the article 
"Adding Data Links to an Existing ESS," also in this issue of the 
Journal. 

5.4 Real-time benefit 

The I/O process that moves the data buffer to a SPUC/DL is 
accomplished at a significant real-time savings compared with the 
I/O interrupt process for LAMA. Whereas LAMA had a data accept- 
ance limitation (primarily related to hardware design) of three bytes 
of data within a 20-millisecond interval, the hardware structure of the 
SPUC/DL allows software definition of the maximum number of data 
bytes in a message. The I/O design in 2BE3 is flexible but currently 
allows 256 bytes of data to be sent to the SPUC/DL during one 100- 
millisecond cycle of the operating systems main loop. Thus, the 
repetitive I/O overhead associated with small segments of information 
pertaining to each LAMA recorded call is very significant compared 
to the AMARC overhead for sending 256 bytes of data for 15 to 20 
calls. The overall real-time savings due to the AMARC billing feature, 
including I/O changes, was 2.8 milliseconds per call (3.6-ms AMARC 
versus 6.4-ms LAMA). This has the effect of increasing the overall 
call-billing capacity of the No. 2B ESS when full measured service is 
offered. 

5.5 Auxiliary registers 

For some cases where the data required for a specific call type 
cannot be contained in a single TCRX register, auxiliary registers are 
provided to hold the overflow data and are referred to as auxiliary 
overflow registers. The auxiliary registers are unique to the AMARC 
feature, while the TCRX registers may be used for other features not 
related to call processing. The auxiliary registers are associated with 
the call by placing an index pointer into the TCRX used for the call. 
Figure 4 shows the connectivity of auxiliary overflow registers plus an 
extension into auxiliary call-forwarding registers. 

5.6 Multiple calls associated with one CAI 

Each leg of a call-forwarded call requires separate billing to each of 
the parties involved with the call. Since separate billing is required, 
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Fig. 4— AMARC message register interrelation. 

the simplest method of administration is to provide a separate initial/ 
answer entry followed by a corresponding disconnect entry for each 
leg of the call. This requires a different CAI for each billed leg and 
thus presented a problem in that the only VEN available at disconnect 
is the originating party VEN. This occurred since the No. 2B ESS 
call-processing structure prior to the 2BE3 generic did not provide a 
record of the intervening call legs once the call was made stable. The 
LAMA billing relied on the CII record table to provide the correct 
billing entry association. In the 2BE3 generic a record of the number 
of billed legs of the call is kept in a Stable Information Entry (SIE) 
during the stable state of the call. The SIE itself is accessed based 
upon the originating party VEN and codes defining the specific use 
for that SIE. 

Correct billing entry association for AMARC call-forwarded billing 
records is achieved by prefixing an incremental count to the CAI at 
answer time for each call -forwarded billing entry except for the first 
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billed leg of the call. The CAI can then be expressed as the CAI = (N- 
1)*2**16 + VEN, where VEN represents the 16 low-order bits of the 
CAI and N equals the billed leg number (1-3) for call-forwarded calls. 
At disconnect, a billing entry is made for each billed leg of the call by 
once again prefixing a count to the CAI for each additional billed leg 
of a call exceeding the first leg. The correct number of disconnect 
entries is determined by the data available in the SIE. 

The initial billing information for call forwarding is collected in the 
associated TCRX and in supplemental auxiliary registers as required. 
As in the case of auxiliary overflow registers, call-forward registers are 
associated with the call by loading an index point to the current 
register into the register servicing the previous leg of the call. An audit 
capability is provided by placing the TCR number in each register. 
Thus, random audits may test a register for activity and, by going to 
the specific TCR, test for the expected connectivity back to the 
auxiliary registers originally interrogated. This connectivity is illus- 
trated in Fig. 4. 

5.7 Retrofit considerations 

Several items of concern exist for the case of an AMARC retrofit 
into an office previously served by LAMA. One concern relating to 
the LAMA/AMARC simultaneous recording requirement during ret- 
rofits is the administration of call types, e.g., measured service, toll, 
etc. LAMA entry codes (equivalent to AMARC call types) relating to 
various calling conditions do not map directly with AMARC call types. 
This required careful preparation of administrative documentation to 
allow in some cases a temporary association of call-type categories for 
LAMA and AMARC. A significant consequence of the call-type asso- 
ciation is the ability of the telephone operating companies to validate 
system operation by comparing the billing records of LAMA and 
AMARC during the retrofit mode of operation. Another consideration 
for the retrofit case is the recovery strategy. Since LAMA was the 
prime billing medium prior to retrofit, all calls billed during the retrofit 
are obtained from LAMA data tapes; thus all failure modes default to 
promoting successful LAMA billing. 

VI. INTEGRATION OF EADAS 

The EADAS feature modified the traffic and plant-collecting and 
printing routines. With the BX.25 protocol as a common base, devel- 
oping the interface requirements became a matter of resolving appli- 
cation-level interfaces between No. 2B ESS, No. 5 ESS, and No. 1A 
EADAS. There are interface differences between the No. 2B ESS to 
No. 1A EADAS and the No. 5 ESS to No. 1A EADAS due to the 
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different architecture structures of No. 2B ESS/generic 2BE3 and No. 
5 ESS. Having the No. 2B ESS conform to the identical interface 
between No. 5 ESS and No. 1A EADAS would cause a real-time 
penalty to No. 2B ESS. The resulting operational interface between 
the No. 2B ESS and No. 1A EADAS is described next. 

6. 1 Basic operation 

The high-speed EADAS interface feature provides for the collection 
and transmittal of both traffic and plant measurement data to No. 1A 
EADAS. With this implementation the traffic and plant measurement 
data are collected on two schedules — a 30-minute schedule and a 24- 
hour schedule. The schedules start collecting 30 seconds before the 
clock 00 minute and 30 minutes and finish by one minute after 00 or 
30. The data are collected and stored in holding registers within 90 
seconds, resulting in a maximum of 90 seconds of data skew. The data 
for most offices will be collected within 30 seconds. The resulting data 
skew of 30 to 90 seconds is significantly more accurate than the 
previous skew of 5 to 15 minutes. Schedules are not transmitted until 
a poll is received from No. 1A EADAS requesting a schedule. The No. 
2B ESS and No. 5 ESS communicate with the 1AED4 generic of No. 
1A EADAS using the BX.25 protocol. 

The interface between the No. 2B ESS and the No. 1A EADAS is a 
poll-and-answer mechanism. The No. 1A EADAS polls for four types 
of data: 

1. Time of day 

2. 30-minute data 

3. 24-hour data 

4. Record base (working member) data. 
The No. 2B ESS answers with the: 

1. Time of day 

2. Data from the H (specified busy hour), C (specified nonbusy 
hour), W (specified weekly), and PLT (specified plant) schedules 

3. D (daily or division of revenue) schedule 

4. Working member count of trunk and service circuits for each 
poll. 

The No. 1A EADAS also sends a message when it is planning to 
discontinue operation temporarily for such things as maintenance. 
The No. 2B ESS accepts the message and prints out a message to the 
TTY to inform the craft. The No. 2B ESS can send error response 
messages to No. 1A EADAS: (1) when the data for a message have 
been overwritten because current polling from the No. 1A EADAS is 
still continuing when the next collection is started, or (2) if a poll 
comes in when the 2B is collecting data for a message. 
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6.2 Data collection 

Data collection is started every quarter hour to collect the inter- 
mediate counts and every half hour to collect the 30-minute counts. 
Also, the 24-hour counts are collected at midnight before the 30- 
minute counts. In Fig. 5 the lines A through H match the description 
of each type of count. The quarter-hour counts, load service measure- 
ments, are moved to the intermediate registers (A and B). The inter- 
mediate registers contain two sets of these registers, the previous 
quarter hour's and the current quarter hour's. The two sets of counts 
are kept until the half hour when both sets are moved to the 30-minute 
holding registers (C and D). Also, every half hour the counts such as 
office totals, service circuit, trunk circuit, multiline hunt, and simu- 
lated groups, junctor usage, centrex, and network usage are moved to 
the 30-minute holding registers (Es). Then the half- hour increment of 
the plant counts are moved to the 30-minute holding registers (Fs and 
Gs). This is done by subtracting from the current plant accumulating 
counts the intermediate plant holding registers, storing the difference 
in the 30-minute holding registers, and moving the accumulating plant 
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counts to the intermediate plant holding registers. The 24-hour counts, 
division of revenue, are moved to the 24-hour holding registers (Hs). 

6.3 Override No. 1A EADAS 

If necessary, the 2BE3 generic can revert to the standard H, C, W, 
and D schedules through human intervention. When an office has 
EADAS active, the 30-minute data are from all the data that could 
have been on the H, C, and W schedules and the 24-hour data are 
from the D schedule. An office could revert to the standard schedule 
output if desired or if the No. 1A EADAS center would go off-line for 
an extended period of time. The No. 2B ESS office would then provide 
the data on hard copy and paper tape punch. In the No. 2B ESS, the 
standard schedules are printed automatically under the control of the 
Traffic Work Table (TWT) from the holding registers. This arrange- 
ment (non-EADAS) does not support RSS EVE engineering needs for 
SPCS COER. This mechanism is overridden when EADAS is active 
and it can be reenabled with a single TTY input message to inhibit 
EADAS. 

6.4 Interface differences 

Because of the differences in No. 2B and No. 5 ESS architecture, 
the interface with No. 1A EADAS does differ on three points: 

1. The No. 2B ESS keeps time differently than the No. 5 ESS. 

2. The No. 2B ESS does not indicate overflow of registers through 
the special register values as does No. 5 ESS. The values 65,526 
through 65,535 are used as special register values, i.e., for overflow, 
bad data, and unequipped register. 

3. The 2B transmits two-byte data low byte first instead of the 
reverse. 

Therefore, the No. 1A EADAS does handle these differences. For 
the No. 2B ESS to have followed the same interface as between No. 5 
ESS and No. 1A EADAS on these three points would have cost the 
No. 2B ESS a real-time penalty. 

VII. SUMMARY 

The addition of the AMARC and EADAS features to the 2BE3 
generic enhanced the No. 2B ESS capability. AMARC achieves the 
billing systems goals of reduced operating expense while providing full 
measured service billing capability for the No. 2B ESS. Also, owing to 
a redistribution of tasks and restructuring of the programs, AMARC 
allows higher call capacity in the No. 2B ESS compared with LAMA 
billing. 

All traffic and plant data are sent to EADAS, which allows for the 
efficient integration of the local switching systems into Total Network 
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Operation Plan (TNOP). Also, owing to the addition of holding 
registers there is virtually no data skew. The EADAS feature is using 
a communication interface that could support network management 
messages and controls in a future generic. 
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